IBIS Macromodel Task Group Meeting date: 15 Jan 2013 Members (asterisk for those attending): Agilent: * Fangyi Rao * Radek Biernacki Altera: * David Banas Julia Liu Hazlina Ramly Andrew Joy Consulting: Andy Joy ANSYS: Samuel Mertens Dan Dvorscak * Curtis Clark Steve Pytel * Luis Armenta Arrow Electronics: Ian Dodd Cadence Design Systems: Terry Jernberg * Ambrish Varma Feras Al-Hawari Brad Brim Kumar Keshavan Ken Willis Cavium Networks: Johann Nittmann Celsionix: Kellee Crisafulli Cisco Systems: Ashwin Vasudevan Syed Huq Ericsson: Anders Ekholm IBM: Greg Edlund Intel: * Michael Mirmak Maxim Integrated Products: Mahbubul Bari * Hassan Rafat Ron Olisar Mentor Graphics: * John Angulo Zhen Mu * Arpad Muranyi Vladimir Dmitriev-Zdorov Micron Technology: Randy Wolff Justin Butterfield NetLogic Microsystems: Ryan Couts Nokia-Siemens Networks: Eckhard Lenski QLogic Corp. * James Zhou SiSoft: * Walter Katz Todd Westerhoff Doug Burns * Mike LaBonte Snowbush IP: Marcus Van Ierssel ST Micro: Syed Sadeghi Teraspeed Consulting Group: Scott McMorrow * Bob Ross TI: Casey Morrison Alfred Chong Vitesse Semiconductor: Eric Sweetman Xilinx: Mustansir Fanaswalla Ray Anderson The meeting was led by Arpad Muranyi ------------------------------------------------------------------------ Opens: - None -------------------------- Call for patent disclosure: - None ------------- Review of ARs: - None ------------- New Discussion: Interconnect Task Group report: - Michael M: - Discussion of [Model] inputs were continued from the previous ATM meeting. - Other EDA vendors again asked to present their views on the [Model] keyword. Arpad: Should we continue the discussion from last week? - Fangyi: We discussed where inputs are analog or digital - This problem is not limited to the alternate flow - The spec does not spell out the input at all - Arpad: Agree the presentation was confusing, linking the problems together - But there is no problem in the existing flow - Fangyi: Why is it only a problem in the alternate flow? - Arpad: That waveform has amplitude variations - Radek: Fangyi is right that the spec does not say what the signal is - The original flow has never been clarified - Arpad: We thought there could be vendor differentiation on that - Radek: The point of a spec is to avoid differences - James: I have seen differences in how EDA tools interpret amplitude - This is not how tools should distinguish themselves - Arpad: The issue is about where the boundaries are drawn - James: This is a different issue - Walter: We have to be clear - IBIS 5.1 has only one standard definition - In time domain the input is a derivative of the step response - It is not specified whether rising or falling step, but they should work the same - In 6.0 we have to say what to do when rise and fall do not match - David: IBIS models don't make digital transitions - Walter: The stimulus does, we assume only low-high and high-low transitions - How the impulse response is generated can lead to numerical issues - That was not put in the standard - There can be artifacts when the response goes through an s-param - James: We just need to say the stimulus is interpreted as a unit amplitude - Walter: When an IBIS model is the analog model the voltage is not 1V - David: James is saying only the input is 1V - Michael M: Digital stimuli in SPICE models are voltage only because that's all they have - Walter: The HSPICE B element does that, but that is not what James is talking about - If the differentiation produces a 3V swing that is a problem - Does it have to be normalized to 1V - Radek: The output doesn't matter, the input does, and there is a voltage divider effect - Arpad: We are using "input" in different ways here - It is the stimulus for this discussion, just a selector, not analog - James: It is just logic, amplitude doesn't matter - That can't be used with AMI_GetWave() where everything is analog - Arpad: Our flow can't give it an analog input - We should decide how to fill this gap and start a BIRD - Michael M: Maybe a new keyword like [Analog AMI Model] would help - Vendors can do something to maintain compatibility with existing models - Fangyi: The only thing different would be a scaling factor - Walter: IC vendors want: - For TX an s4p with series termination value and voltage swing - Or series impedance, c_comp, and voltage swing - For RX an s4p with termination value to ground - Or c_comp and termination value to ground - Arpad: Why not [External Model]? - Walter: The D-to-A converters are not needed Arpad showed a slide about modified [External Model] - Walter: This requires an external subckt, more complicated than needed - A mechanism to specify the analog model from AMI or the DLL is needed - Michael M: This is about whether the structure of [External Circuit] works for AMI - Arpad: One problem is that [Model] is single ended - [External Model] should be an easy way to get where we want - Fangyi: The content of [External Model] needs to be addressed - Arpad: This shows a way to connect any analog voltage, it can be completely analog - Radek: Whether we use [External Model] or direct s4p call we have to clarify voltage - Arpad: A TOUCHSTONE parameter inside a [Model] is a problem because it is single ended - Radek: [External Model] has the same problem - Mike L: If two diff pins call different models we might have the same problem already - Walter: EDA vendors are already doing this, but it needs to be documented - Not many models out there have [External Model] - We should not complicate things by using it - Radek: We may want to consider more comprehensive solutions - Walter: [External Model] still makes no sense - Michael M: We must have a solution so that no one is left behind - Arpad: We need a list of what we want in the model, to decide how we are going to do it - Then we can start writing BIRDs - Michael M: David sent a survey question asking about how GetWave is used and a 5.10 flow question - Walter: That is unrelated to this - We need a clear way to allow IC vendors to generate broadband models - David: I have not heard any IC vendors confirm how it works - Walter: There will be presentations at DesignCon to clarify it Arpad: Our next meeting will be Feb 5, after DesignCon ------------- Next meeting: 2 Feb 2013 12:00pm PT Next agenda: 1) Task list item discussions ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives